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Abstract. The ESAC Gaia team engages in a form of eXtreme pro- 
gramming while the DPAC will follow a series of six month development 
cycles modeled on this approach. As a project within the European Space 
Agency the European Committee for Space Standardization (ECSS) stan- 
dards are required. We present the bringing together of these realms. 



1. Introduction 

ECSS standards may be difficult to understand and without good tailoring are 
not well suited to the development of science processing software. Here we tell 
the DPAC story so far. 



2. The Gaia Satellite and Science 

The Gaia payload consists of three distinct instruments for astrometric, pho- 
tometric and spectroscopic measurements, mounted on a single optical bench. 
Unlike HST and SIM, which are pointing missions observing a preselected list 
of objects, Gaia is a scanning satellite that will repeatedly survey in a system- 
atic way the whole sky. The main performances of Gaia expressed with just 
a few numbers are just staggering and account for the vast scientific harvest 
awaited from the mission: a complete survey to 20th magnitude of all point 
sources amounting to more than one thousand million objects, with an astro- 
metric accuracy of 12-25 //as at 15th magnitude and 7 //as for the few million 
stars brighter than 13th magnitude; radial velocities down to 17th magnitude, 
with an accuracy ranging from 1 to 15kms _1 ; multi-epoch spectrophotometry 
for every observed source sampling from the visible to the near IR. 

Gaia is being constructed by EADS Astrium under contract from ESA and 
is scheduled for launch at the end of 2012. It is to spend five years at L2 carrying 
out its survey. The 35 meter antenna in Cebrerros Spain (an occasionally New 
Norcia) will be used to downlink about 100 Terabytes of data. 



3. The Astrometric Global Iterative Solution (AGIS) 

The astrometry of Gaia is calculated from the multiple observations in different 
directions of the five years of the mission. The approach to this data reduction 
is a block iterative robust least squares fitting of the data as presented at the 
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Figure 1. Royce's waterfall model (left) reproduced from Royce 1970. 
This is held to be the original waterfall approach but it is a scheme 
which Royce's paper claims is flawed. The right figure appears later in 
the same paper. 



last ADASS (O'Mullane et al. 2007). Briefly objects are matched from the 
successive scans, attitude (three dimensional orientation of the satellite) and 
calibrations are updated. Next the object positions are solved followed by higher 
order terms usually referred to as global parameters (such as PPN 7). This 
reduction provides us with : observed (proper) directions to a subset of well- 
behaved (primary) sources, attitude of the instrument as function of time and 
transformation from field angles to pixel coordinates. This requires selecting 
10 8 of the 10 9 sources as input to the process and treating, iteratively, the 10 1 
transits. 



4. Is development of Science software different ? 

The author conducted a survey over one year of many large science developments 
O'Mullane 2005. This proved to be a most interesting study and concluded that 
science software development is indeed different to traditional software develop- 
ment due to the funding structure and general approach to leadership. This is 
in any case quite different to a satellite development project. Yet large organ- 
isations still wish to see developments like Gaia in a more traditional waterfall 
model. The approach to development within DPAC of using cycles and always 
having some working software leans much more toward the Agile techniques dis- 
cussed here than traditional project management. Indeed these days there are 
few if any software companies remaining who follow the waterfall approach to 
development. The most lamentable thing of all is perhaps that Royce, attributed 
with the waterfall model, showed the waterfall approach in Royce 1970 (see Left 
FigJT]) as an example of the flawed way to do software development. Later in 
the same paper Royce (see Right Fig. [I]) he argues one should " do it twice" . 

He points out the flaw in that it is a long time before implementation starts 
and real problems are seen. These real problems may fundamentally change 
requirements. All of these ideas are in line with Agile approaches. Our intention 
is to do it far more than twice - about ten times for DPAC. Even the preliminary 
AGIS went through several iterations before it was ready. 
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The perhaps the fundamental difference between science software devel- 
opment and satellite development is perhaps the risk element. Often for the 
software we may not know exactly how a particular problem will be solved or 
indeed if it may be solved. It would be a huge mistake to discard certain solu- 
tions simply to make a good plan (which is after all what most managers would 
like to see). Let us take some examples. 

5. eXtreme development approach 

No we do not all huddle around a single computer at ESAC but we have taken 
some useful ideas from the eXtreme programming field such as presented by 
Beck 1999. Planning is done on a monthly basis, stories are written and costed 
in points (where lpoint ~ \/2day). The cost is agreed as a team not set by a 
manager. Team members are also given points with which they buy the stories 
they wish to work on. Some stories of course must be bought first but generally 
team members should be able to have some story they would like to do in addition 
to the stories they em must do. All stories are entered in the Xp Tracker, a Twiki 
plugin designed for eXtreme programming. 

Code, in general, is owned by the group - any developer may improve code. 
Code reviews are carried out frequently as a group where developers modify 
code and comments as well as raise issues. In this way we try to keep code 
in adherence with he agreed coding standards as well as keeping documentation 
valid and up to date. Such an open system only works with excellent test harness 
in place. We use JUnit to write tests and place emphasis on good test coverage 
(looking for 80 to 100%). CruiseControl is employed to regually check out code, 
build it and run all of the JUnit tests. Developers must keep tests passing when 
any modification is made to the code. The AGIS system ,for example, contains 
100K lines of Java, 30K lines of test code and 90K lines of comments. 

6. European Cooperation for Space Standardization (ECSS) 

The European Space Agency (ESA) generally is more involved with satellite con- 
struction which follows a waterfall model of development. Indeed for hardware 
production there is little choice. Springing from this background the ECSS stan- 
dards tell us how we should do a project, what documents should be produced 
when and, to some degree, what they should contain. The standards come as a 
long list of books for example : ECSS-E-10B Requirements , ECSS-M-30A Phas- 
ing, ECSS-M-40B Configuration Management, ECSS-Q-20B Quality Assurance, 
etc. 

The also come with a set of reviews which should be held which hark back 
tot he waterfall they are the System Requirements Review, the Preliminary 
Design Review, the Critical Design Review, the Qualification Review and the 
Acceptance Review. ECSS is considered applicable also to the ground segment 
software which includes the science processing software. 

In reality ECSS is very flexible - perhaps too flexible, it must be tailored 
to a particular project. Clearly some of the ECSS is not applicable to software 
production so a tailoring must be undertaken. This outlines which parts of ECSS 
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Figure 2. Gaia DPAC document tree matching ECSS 



will be used for the project and define to some extent the document tree (see 
Figure E]). 



7. Conclusion 

The usefulness of an eXtreme programming approach has been demonstrated for 
the AGIS software at ESAC. In general this sort of approach is very well suited 
to scientific software development. If this will work in the scaled up manner 
for DPAC does remain to be seen. Every project needs documentation and 
with a little effort the ECSS has been em tailored and a useful set of standard 
documentation outlined. Templates for these documents have been created. 
There remains considerable pressure toward more em traditional techniques for 
DPAC. Daily reading of Dilbert is recommended for sanity. 
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